Support Horizontal Scaling#1048
Conversation
pleshakov
left a comment
There was a problem hiding this comment.
more comments:
(1) Would it make sense to add something about leader election to the architecture doc?
(2) What removes the leader election lock resource? Do we need to update our deinstallation instructions (helm and manifests) if it is not removed automatically?
(1) Sure, I can add something to the architecture doc. |
50e907a to
d4b4423
Compare
|
There is a line here that is: "Once we add leader election, the control plane will be able to scale.", would we like to change that now? |
No, that's in an old design document. We don't need to keep those up-to-date. |
f0f0ed8 to
ed875d2
Compare
Co-authored-by: bjee19 <139261241+bjee19@users.noreply.github.com>
Co-authored-by: bjee19 <139261241+bjee19@users.noreply.github.com>
ed875d2 to
28cd3b1
Compare
Problem: NKG cannot be scaled horizontally because all replicas will write statuses to the Gateway API resources. Solution: Add leader election to the status updater so that only one replica of NKG will write statuses to the Gateway API resources. Leader election is enabled by default but can be disabled via a cli arg --leader-election-disable. The lock name used for leader election can be configured via the cli arg --leader-election-lock-name.
Proposed changes
Problem: NKG cannot be scaled horizontally because all replicas will write statuses to the Gateway API resources.
Solution: Add leader election to the status updater so that only one replica of NKG will write statuses to the Gateway API resources. Leader election is enabled by default but can be disabled via a cli arg
--leader-election-disable. The lock name used for leader election can be configured via the cli arg--leader-election-lock-name.Testing: Verified leader election works with multiple replicas.
Closes #637
Checklist
Before creating a PR, run through this checklist and mark each as complete.